Fix gpactivatestandby after clean shutdown. - #1889
Conversation
A forced activation previously relied on promote_trigger_file before starting the stopped standby, allowing startup to reach catalog access while recovery was still completing. Start the standby with GpStandbyStart and perform the normal pg_ctl promotion before reading the catalog. Share one 600-second monotonic deadline across startup, promotion, and the utility CHECKPOINT retry. Keep activation-specific handling out of gpstart and leave its CLI unchanged.
There was a problem hiding this comment.
Hi! Great! By the way, do not want to add run beehave tests in CI? I think we do not launch them, but have fixes in python environment. It will be great to check if everything is Ok here
There was a problem hiding this comment.
Hi! The gpMgmt Behave tests were previously part of the legacy Concourse pipeline, which was removed in a9cc251
Re-enabling them in the current CI would require reviewing and updating the existing tests, dependencies, and CI environment. I think this should be tracked in a separate issue, where we can discuss whether these tests should be added to the current CI and how. What do you think?
There was a problem hiding this comment.
I did a draft work in #1639, FYI. However, I don't have any more energy for it. If available, welcome to take over it.
There was a problem hiding this comment.
I did a draft work in #1639, FYI. However, I don't have any more energy for it. If available, welcome to take over it.
There could be a chance that failed tests just shows us there are real issue in our code.
And the CI is great, we just should fix bugs in our repo
3 participants
Fixes #1717.
For forced activation of a stopped standby, start the postmaster directly with
GpStandbyStartinstead of usingpromote_trigger_fileandgpstart. Then promote it withpg_ctl promote, wait for a successful utilityCHECKPOINT, read the catalog, and restart the segments.The existing 600-second
pg_ctl promotetimeout is preserved. A single monotonic deadline covers standby startup, promotion, and the utilityCHECKPOINT, preventing these waits from accumulating while leaving segment restart to its existing timeout handling.